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Abstract —We present a proof by induction algorithm, which 
combines ^-induction with invariants to model check embedded 
C software with bounded and unbounded loops. The A-induction 
algorithm consists of three cases: in the base case, we aim to find 
a counterexample with up to k loop unwindings; in the forward 
condition, we check whether loops have been fully unrolled and 
that the safety property (p holds in all states reachable within k 
unwindings; and in the inductive step, we check that whenever p 
holds for k unwindings, it also holds after the next unwinding of 
the system. For each step of the A-induction algorithm, we infer 
invariants using affine constraints (i.e., polyhedral) to specify pre- 
and post-conditions. Experimental results show that our approach 
can handle a wide variety of safety properties in typical embedded 
software applications from telecommunications, control systems, 
and medical devices; we demonstrate an improvement of the in¬ 
duction algorithm effectiveness if compared to other approaches. 

L Introduction 

The Bounded Model Checking (BMC) techniques based on 
Boolean Satisfiability (SAT) or Satisfiability Modulo Theories 
(SMT) have been applied to verify single- and multi-threaded 
programs and to find subtle bugs in real programs ID, El, El. 
The idea behind the BMC techniques is to check the negation 
of a given property at a given depth, i.e., given a transition 
system M, a property cp, and a limit of iterations k, BMC 
unfolds the system k times and converts it into a Verification 
Condition (VC) ip such that tp is satisfiable if and only if cp 
has a counterexample of depth less than or equal to k. 

Typically, BMC techniques are only able to falsify prop¬ 
erties up to a given depth k; they are not able to prove the 
correctness of the system, unless an upper bound of k is known, 
i.e., a bound that unfolds all loops and recursive functions to 
their maximum possible depth. In particular, BMC techniques 
limit the visited regions of data structures (e.g., arrays) and the 
number of loop iterations. This limits the state space that needs 
to be explored during verification, leaving enough that real 
errors in applications ID, El, El, El can be found; BMC tools 
are, however, susceptible to exhaustion of time or memory 
limits for programs with loops whose bounds are too large or 
cannot be determined statically. 

Consider for example the simple program in Fig. [D (top), 
in which the loop in line 2 runs an unknown number of times, 
depending on the initial non-deterministic value assigned to 
X in line 1. The assertion in line 3 holds independent of 
x’s initial value. Unfortunately, BMC tools like CBMC ID, 
LLBMC ID, or ESBMC ID typically fail to verify programs 
that contain such loops. Soundness requires that they insert a 


so-called unwinding assertion (the negated loop bound) at the 
end of the loop, as in Fig. [D (bottom), line 5. This unwinding 
assertion causes the BMC tool to fail if k is too small. 

In mathematics, one usually attacks such unbounded prob¬ 
lems using proof by induction. A variant called k-induction has 
been successfully combined with continuously-refined invari¬ 
ants El, to prove that (restricted) C programs do not contain 
data races 0, El, or that design-time time constraints are 
respected 0. Additionally, k-induction is a well-established 
technique in hardware verification, where it is easy to apply 
due to the monolithic transition relation present in hardware 
designs 0, 0, Eol. This paper contributes a new algorithm 
to prove correctness of C programs by k-induction in a 
completely automatic way. 

1 unsigned int x = *; 

2 while(x>0) X—; 

3 assert (x ==0); 


1 unsigned int x = *; 

2 if (x>0) 'j 

3 X-; ^ k copies 

5 assert (! ( x >0)); 

6 assert (x ==0); 


Fig. 1: Unbounded loop (top) and finite unwinding (bottom) 

The main idea of the algorithm is to use an iterative 
deepening approach and check, for each step k up to a 
maximum value, three different cases called here as base case, 
forward condition, and inductive step. Intuitively, in the base 
case, we intend to find a counterexample of (p with up to k 
iterations of the loop. The forward condition checks whether 
loops have been fully unrolled and the validity of the property 
(p in all states reachable within k iterations. The inductive step 
verifies that if <p is valid for k iterations, then <p will also be 
valid for the next unfolding of the system. For each step, we 
infer invariants using affine constraints to prune the state space 
exploration and to strengthen the induction hypothesis. 

These algorithms were all implemented in the Efficient 
SMT-based Context-Bounded Model Checker tool (known as 
ESBMC), which uses BMC techniques and SMT solvers to 
verify embedded systems written in C/C-f-l- 0, ED- In 
Cordeiro et al. 0, ED the ESBMC tool is presented, which 
describes how the input program is encoded in SMT; what 
the strategies for unrolling loops are; what are the trans- 





formations/optimizations that are important for performance; 
what are the benefits of using an SMT solver instead of a 
SAT solver; and how counterexamples to falsify properties are 
reconstructed. Here we extend our previous work and focus our 
contribution on the combination of the k-induction algorithm 
with invariants. First, we describe the details of an accurate 
translation that extends ESBMC to prove the correctness 
of a given (safety) property for any depth without manual 
annotations of loops invariants. Second, we adopt program 
invariants (using polyhedra) in the k-induction algorithm, to 
improve the quality of the results by solving more verification 
tasks. Third, we show that our implementation is applicable to 
a broader range of verification tasks; in particular embedded 
systems, where existing approaches do not to support ||6|, Q, 

M- 

II. Induction-based Verification of C Programs 
USING Invariants 

The transformations in each step of the k-induction al¬ 
gorithm take place at the intermediate representation level, 
after converting the C program into a GOTO-program, which 
simplifies the representation and handles the unrolling of the 
loops and the elimination of recursive functions. 

A. The Proposed k-Induction Algorithm 

Figure shows an overview of the proposed k-induction 
algorithm. The input of the algorithm is a C program P 
together with the safety property (j). The algorithm returns 
TRUE (if there is no path that violates the safety property), 
FALSE (if there exists a path that violates the safety property), 
and UNKNOWN (if it does not succeed in computing an 
answer true or false). 

In the base case, the algorithm tries to find a counterexam¬ 
ple up to a maximum number of iterations k. In the forward 
condition, global correctness of the loop w.r.t. the property is 
shown for the case that the loop iterates at most k times; and in 
the inductive step, the algorithm checks that, if the property is 
valid in k iterations, then it must be valid for the next iterations. 
The algorithm runs up to a maximum number of iterations and 
increases the value of k if it cannot falsify the property. In 
Figure |2] the algorithm also performs a rechecking/refinement 
of the result (using the flag f orce_basecase) by the BMC 
procedure. In particular, we re-check the results in the forward 
condition and the inductive step (adopting an increment of the 
actual k). This re-checking procedure is needed due to the 
inclusion of invariants, which over-approximates the analyzed 
program; otherwise, the invariants could result in incorrect 
exploration of the states sets. 

1) Loop-free Programs: In the k-induction algorithm, the 
loop unwinding of the program is done incrementally from one 
to max_iterations (cf. Fig.|2]), where the number of unwindings 
is measured by counting the number of backjumps M- In each 
step, an instance of the program that contains k copies of the 
loop body corresponds to checking a loop-free program, which 
uses only if-statements in order to prevent its execution in the 
case that the loop ends before k iterations. 

Definition 1: (Loop-free Program) A loop-free program 
is represented by a straight-line program (without loops) by 
providing an ite {9, pi, P 2 ) operator, which takes a Boolean 
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input: program P and safety property f 
output: true , false , or unknown 
k = 1 

force_basecase = FALSE 
last_result = UNKNOWN 
w hile k <= max_iterations do 
if force_basecase then 
k = k -H 5 

if base_case(P, 0, k) then 
show counterexample s[0..k] 
return FALSE 
else 

if force_basecase then 
return last_result 
k=k-i-l 

if forward_condition (P, f, k) then 
force_basecase = TRUE 
last_result = TRUE 
else 

if induetiVe_step (P , f , k) then 
force_basecase = TRUE 
last_result = TRUE 

end—if 
end—if 
end—if 
end—while 
return UNKNOWN 


Fig. 2: An overview of the k-induction algorithm. 


formula 6 and, depending on its value, selects either the second 
Pi or the third argument p 2 , where pi represents the loop body 
and p 2 represents either another ite operator, which encodes 
a k-copy of the loop body, or an assertion/assume statement. 

Each step of our k-induction algorithm (except for the 
base case) transforms a program with loops into a loop-free 
program, such that the correctness of the loop-free program 
implies the correctness of the program with loops. 

If the program consists of multiple and possibly nested 
loops, we simply set the number of loop unwindings globally, 
that is, for all loops in the program and apply these afore¬ 
mentioned translations recursively. Note that each case of the 
k-induction algorithm performs different transformations at the 
end of the loop: either to And bugs (base case) or to prove that 
enough loop unwindings have been done (forward condition). 

2 ) Program Transformations: In terms of program transfor¬ 
mations, which are all done completely automatically by our 
proposed method, the base case simply inserts an unwinding 
assumption, to the respective loop-free program P', consisting 
of the termination condition a after the loop, as follows 
I A T A a ^ cj>, where I is the initial condition, T is the 
transition relation of P', and f is a safety property. 

The forward case inserts an unwinding assertion instead of 
an assumption after the loop, as follows I AT ^ a Af. Our 
base case and forward condition translations are implemented 
on top of plain BMC. However, for the inductive step of the 
algorithm, several transformations are carried out. In particular, 
the loop while{c) {E; } is converted into 

A] while{c) {S'; (7; } i?; 


( 1 ) 



where A is the code responsible for assigning non- 
deterministic values to all loop variables, i.e., the state is 
havocked before the loop, c is the exit condition of the loop 
while, S is the code to store the current state of the program 
variables before executing the statements of E, E is the actual 
code inside the loop while, U is the code to update all program 
variables with local values after executing E, and R is the code 
to remove redundant states. 

Definition 2: (Loop Variable) A loop variable is a vari¬ 
able V V, where V = Vgiobai U Viocai given that Vgiobai 
is the set of global variables and Viocai is the set of local 
variables that occur in the loop of a program. 

Definition 3: (Havoc Loop Variable) A nondeterministic 
value is assigned to a loop variable v if and only if v is used 
in the loop termination condition a, in the loop counter that 
controls iterations of a loop, or modified inside the loop body. 

The intuitive interpretation of S, U, and R is that if the current 
state (after executing E) is different than the previous state 
(before executing E), then new states are produced in the given 
loop iteration; otherwise, they are redundant and the code R 
is then responsible for preventing those redundant states to be 
included into the states vector. Note further that the code A 
assigns non-deterministic values to all loop variables so that 
the model checker can explore all possible states implicitly. 
Similarly, the loop for can easily be converted into the loop 
while as follows: for{B; c; D) {E; } is rewritten as 

B; while{c) {E] D]} (2) 

where B is the initial condition of the loop, c is the exit 
condition of the loop, D is the increment of each iteration over 
B, and E is the actual code inside the loop for. No further 
transformations are applied to the loop/or during the inductive 
step. Additionally, the loop do while can be converted into the 
loop while with one difference, the code inside the loop must 
execute at least once before the exit condition is checked. 

The inductive step is thus represented by 7 A cr ^ where 
7 is the transition relation of P', which represents a loop- 
free program (cf. Definition [T]i after applying transformations 
O and (IDi. The intuitive interpretation of the inductive step 
is to prove that, for any unfolding of the program, there is 
no assignment of particular values to the program variables 
that violates the safety property being checked. Finally, the 
induction hypothesis of the inductive step consists of the 
conjunction between the postconditions {Post) and the ter¬ 
mination condition (cr) of the loop. 

3) Invariant Generation: To infer program invariants, we 
adopted the PIPS ifTSll tool, which is an interprocedural source- 
to-source compiler framework for C and Fortran programs and 
relies on a polyhedral abstraction of program behavior. PIPS 
performs a two-step analysis: ( 1 ) each program instruction is 
associated to an affine transformer, representing its underlying 
transfer function. This is a bottom-up procedure, starting from 
elementary instructions, then working on compound statements 
and up to function definitions; ( 2 ) polyhedral invariants are 
propagated along with instructions, using previously computed 
transformers. 

In our proposed method, PIPS receives the analyzed pro¬ 
gram as input and then it generates invariants that are given as 


comments surrounding instructions in the output C code. These 
invariants are translated and instrumented into the program 
as assume statements. In particular, we adopt the function 
assume {expr) to limit possible values of the variables 
that are related to the invariants. This step is needed since 
PIPS generates invariants that are presented as mathematical 
expressions (e.g., 2j < 5t), which are not accepted by C 
programs syntax and invariants with pinit suffix that is used 
to distinguish the old value from the new value. 

Algorithm [T] shows the proposed method, which receives 
as inputs the code generated by PIPS (PIPSCode) with 
invariants as comments, and it generates as output a new 
instance of the analyzed code (NewCodelnv) with invariants, 
adopting the function assume (expr), where expr is an 
expression supported by the C programming language. The 
time complexity of this algorithm is OirP), where n is code 
size with invariants generated by PIPS. The algorithm is split 
into three parts: (1) identify the #init structure in the PIPS 
invariants; ( 2 ) generate code to support the translation of the 
#init structure in the the invariant; and finally (3) translate 
mathematical expressions contained in the invariants, which is 
performed by the invariants transformation in the PIPS format 
to the C programming language. 


Input: PIPSCode - C code with PIPS invariants 
Output: NewCodelnv - New code with invariant supported by C 
programs 

1 dict_variniteloc } 

2 NewCodelnv •<— { } 

// Part 1 - identifying #init 

3 foreach line of the PIPSCode do 

4 if is a PIPS comment in this pattern // P (vi, x) 

{to == 0/ xH^init > 10} then 

if the comment has the pattern 
([a-zA-Z0-9_] +) #init then 

6 I dict_variniteloc [line] •<—the variable suffixed #init 

7 end 
end 

9 end 

// Part 2 - code generation 

10 foreach line of PIPSCode do 

11 NewCodelnv line 

12 if is the beginning of a function then 

13 if has some line number of this junction G 
dict_variniteloc then 

14 foreach variable G dict_variniteloc do 

15 I NewCodelnv Declare a variable with this 

pattern type var_init = var; 

16 end 

17 end 

18 end 

19 end 

// Part 3 - correct the invariant format 

20 foreach line of NewCodelnv do 

21 listinvpips } 

22 NewCodelnv -(r- line 

23 if is a PIPS comment in this pattern // P (w, x) 

{id == 0, xj^init > 10} then 

24 foreach expression G {w == 0, xj^init > 10} do 

25 listinvpips Refonnulate the expression according 

to the C programs syntax and replace by 

_init 

end 

NewCodelnv _ESBMC_assume(concatenate the 

invariants in listinvpips with &&) 

end 


26 

27 


end 


Algorithm 1: Translation algorithm of invariants 











Line[3]of Algorithm[T]performs the first part of the invariant 
translation, which consists of reading each line of the analyzed 
code with invariants and identifying whether a given comment 
is an invariant generated by PIPS (line ID). If an invariant is 
identified and it contains the structure #int, then the invariant 
location (the line number) is stored, as well as, the type and 
name of the variable, which has the prefix #int (line|6]l. 

After identifying the #int structures in the invariants, the 
second part of Algorithm [T] performs line [TOl which consists 
of reading each line of the analyzed code with invariants 
(PIPSCode), and identifying the beginning of each function 
in the code. For each identified function, the algorithm checks 
whether that function has identified some #int structure 
(line [TSl l. If it has been identified, for each variable that 
has the suffix #int, a new line of code is generated at the 
beginning of the function, with the declaration of an auxiliary 
variable, which contains the old variable value, i.e., its value 
at the beginning of the function. During the execution of 
this algorithm, a new instance of the code (NewCodelnv) 
is generated. 

In the third (and final part) of Algorithm [T] (line [20b . 
each line of the new code instance (NewCodelnv) is read to 
convert each PIPS invariant into expressions supported by the 
C language. This transformation consists in applying regular 
expressions (line l25l l to add operators (e.g., from 2j to 2 * j) 
and replacing the structure #int to _int. For each analyzed 
PIPS comment/invariant, we generate a new code line to the 
new format, where this line is concatenated with the operator 
&& and added to the_ ESBMC_assume function. 

III. Experimental Evaluation 

This section is split into two parts. The setup is described in 
Section lljl-Al and Section ITlI-BI describes a comparison among 
DepthKQ, ESBMC E), CBMC d, and CPAchecker 0 using 
a set of C benchmarks from SV-COMP Qll and embedded 
applications ifTSl . ifTbl . ifTTl . 

A. Experimental Setup 

The experimental evaluation is conducted on a computer 
with Intel Xeon CPU ES - 2670 CPU, 2.60GHz, 115GB 
RAM with Linux 3.13.0 — 35-generic x86_64. Each veri¬ 
fication task is limited to a CPU time of 15 minutes and 
a memory consumption of 15 GB. Additionally, we defined 
the max_iterations to 100 (cf. Pig. EJ. To evaluate all tools, 
we initially adopted 142 ANSI-C programs of the SV-COMP 
2015 benchmarks; in particular, the Loops subcategory; and 34 
ANSI-C programs used in embedded systems: Powerstone M 
contains a set of C programs for embedded systems (e.g., 
for automobile control and fax applications); while SNU real¬ 
time ini contains a set of C programs for matrix and signal 
processing functions such as matrix multiplication and decom¬ 
position, quadratic equations solving, cyclic redundancy check, 
fast fourier transform, LMS adaptive signal enhancement, and 
JPEG encoding; and the WCET QS) contains C programs 
adopted for worst-case execution time analysis. 

We also present a comparison with the tools: DepthK 
vl.O with fc-induction and invariants using polyhedra, the 

’ https://github.com/hbgit/depthk 


parameters are defined in the wrapper script available in the 
tool repository; ESBMC vl.25.2 adopting /c-induction without 
invariants. We adopted the wrapper script from SV-COMP 
201;E to execute the tool; CBMC v5.0 with fc-induction, run¬ 
ning the script provided in 0 ; CPACheckefl with fc-induction 
and invariants at revision 15596 from its SVN repository. The 
options to execute the tool are defined in 0. 

B. Experimental Results 

After running all tools, we obtained the results shown in 
Table H for the SV-COMP 2015 benchmark and in Table |II] 
for the embedded systems benchmarks, where each row of 
these tables means: name of the tool (Tool); total number 
of programs that satisfy the specification (correctly) identified 
by the tool (Correct Results); total number of programs that 
the tool has identified an error for a program that meets the 
specification, i.e., false alarm or incomplete analysis (Ealse 
Incorrect); total number of programs that the tool does not 
identify an error, i.e., bug missing or weak analysis (True 
Incorrect); Total number of programs that the tool is unable to 
model check due to lack of resources, tool failure (crash), or 
the tool exceeded the verification time of 15 min (Unknown 
and TO); the run time in minutes to verify all programs (Time). 

We evaluated all tools as follows: for each program we 
identified the verification result and time. We adorned the same 
scoring scheme that is used in SVCOMP 2010 Eor every 
bug found, 1 score is assigned, for every correct safety proof, 
2 scores are assigned. A score of 6 is subtracted for every 
wrong alarm (Ealse Incorrect), and 12 scores are subtracted for 
every wrong safety proof (True Incorrect). According to 0, 
this scoring scheme gives much more value in proving proper¬ 
ties than finding counterexamples, and significantly punishes 
wrong answers to give credibility for tool developers. It is 
noteworthy that for the embedded systems programs, we have 
used safe programs 0 since we intend to check whether we 
produce strong invariants to prove properties. 

The experimental results related to Loops benchmarks had 
shown that the best scores belong to the DepthK, which 
combines fc-induction with invariants, achieving 140 scores, 
ESBMC with fc-induction without invariants achieved 105 
scores, CPAchecker no-inv k-induction achieved 101 scores, 
and CBMC achieved 53 scores. In the embedded systems 
benchmarks, we found that the best scores belong to the 
CPAchecker no-inv k-induction with 54 scores, ESBMC with 
fc-induction without invariants achieved 36 scores, DepthK 
combined with fc-induction and invariants, achieved 34 scores, 
and CBMC achieved 30 scores. 

We observed that DepthK achieved a lower score in the 
embedded systems benchmarks. However, the DepthK results 
are still higher than that of CBMC; and in the SV-COMP 
benchmark, DepthK achieved the highest score among all 
tools. In DepthK, we identified that, in turns, the low score 
in the embedded systems benchmarks is due to 35.30% of the 
results identified as Unknown, i.e., when it is not possible 
to determine an outcome or due to a tool failure. We also 
identified failures related to invariant generation and code 

^http://sv-comp.sosy-Iab.org/20I3/ 

^ https://svn.sosy-lab.org/software/cpachecker/trunk 
'*http://sv-comp.sosy-lab.org/2015/rules.php 








Tool 

DepthK 

ESBMC + 
k-induction 

CPAchecker no-inv 
k-Induction 

CPAchecker cont.-ref. 
k-Induction (k-Ind InvGen) 

CBMC + 
k-induction 

Correct Results 

94 

70 

78 

76 

64 

False Incorrect 

1 

0 

0 

1 

3 

True Incorrect 

0 

0 

4 

7 

1 

Unknown and TO 

47 

72 

60 

58 

74 

Time 

190.38min 

141.58min 

742.58min 

756.01min 

1141.17min 


TABLE I: Experimental results for the SVCOMP’15 loops subcategory. 


Tools 

DepthK 

ESBMC -h 
k-induction 

CPAchecker no-inv 
k-Induction 

CPAchecker cont.-ref. 
k-Induction (k-Ind InvGen) 

CBMC -h 
k-induction 

Correct Results 

17 

18 

27 

27 

15 

False Incorrect 

0 

0 

0 

0 

0 

True Incorrect 

0 

0 

0 

0 

0 

Unknown and TO 

17 

16 

7 

7 

19 

Time 

77.68min 

54.18min 

l.Smin 

1.95min 

286.06min 


TABLE II: Experimental results for the Powerstone, SNU, and WCET benchmarks. 


generation that is given as input to the BMC procedure. It 
is noteworthy that DepthK is still under development (in a 
preliminary state), so we argue that the results are promising. 

To measure the impact of applying invariants to the k- 
induction based verification, we classified the distribution of 
the DepthK and ESBMC results, per verification step, i.e., base 
case, forward condition, and inductive step. Additionally, we 
included the verification tasks that result in unknown and 
timeout. In this analysis, we evaluate only the results of 
DepthK and ESBMC, because they are part of our solution, 
and also because in the other tools, it is not possible to identify 
the steps of the fc-induction in the standard logs generated by 
each tool. 

The result distribution shows that DepthK can prove more 
than 25.35% and 29.41% of the loops and embedded systems 
properties than ESBMC during the inductive step, respec¬ 
tively. These results lead to the conclusion that invariants 
help the k-induction algorithm to prove more properties. We 
also identified that DepthK did not find a solution in 33.09% 
of the programs in the SV-COMP benchmarks and 50% in 
the embedded systems benchmarks (producing Unknown and 
Timeout). This is explained due to the invariants generated 
from PIPS, which are not strong enough for the verification 
with the /c-induction, either due to a transformer or due to the 
invariants that are not convex; and also due to some errors 
in the tool implementation. ESBMC with fc-induction did not 
find a solution in 50.7% of the programs in the SV-COMP 
benchmark, i.e., 17.61% more than DepthK (adding Unknown 
and Timeout); and in the embedded benchmarks, ESBMC 
did not find a solution in 47.06%, then only 3.64% less than 
the DepthK, thus providing evidences that the program invari¬ 
ants combined with fc-induction can improve the verification 
results. 

In Table U the verification time of DepthK to the loops 
benchmarks is usually faster than the other tools, except for 
ESBMC, as shown in Eigure [3 This happens because DepthK 
has an additional time for the invariants generation. In Table HU 
we identified that the verification time of DepthK is only faster 


than CBMC (see Eigure |4]i. However, note that the DepthK 
verification time is proportional to ESBMC, since the time 
difference is 23.5min; we can argue that this difference is 
associated to the DepthK invariant generation. 

We believe that DepthK verification time can be improved 
in two directions: fix errors in the tool implementation, because 
some results generated as Unknown are related to failures 
in the tool execution; and adjustments in the PIPS script 
parameters to generate stronger invariants, since PIPS has a 
broad set of commands for code transformation, parameter 
tuning might have a positive impact. 

IV. Related Work 

The fc-induction application is gaining popularity in the 
software verification community. Recently, Bradley et al. in¬ 
troduce “property-based reachability” (or IC3) procedure for 
the safety verification of systems mi, mi. The authors have 
shown that IC3 can scale on certain benchmarks, where fc- 
induction fails to succeed. However, we do not compare fc- 
induction against IC3 since it is already done by Bradley mi; 
we focus our comparison on related fc-induction procedures. 

Previous work on the one hand have explored proofs by 
mathematical induction of hardware and software systems 
with some limitations, e.g., requiring changes in the code 
to introduce loop invariants 0, a. This complicates the 
automation of the verification process, unless other methods 
are used in combination to automatically compute the loop 
invariant mi, mi. Similar to the approach proposed by ll22l . 
Q, our method is completely automatic and does not require 
the user to provide loops invariants as the final assertions after 
each loop. On the other hand, state-of-the-art BMC tools have 
been widely used, but as bug-finding tools since they typically 
analyze bounded program runs |[T], |l2l. This paper closes this 
gap, providing clear evidence that the fc-induction algorithm in 
combination with invariants can be applied to a broader range 
of C programs without manual intervention. 

GroBe et al. describe a method to prove properties of 
Transaction Level Modeling designs in SystemC El. The 
























Tools CBMC CPAchecker (k-Ind InvGen) CPAchecker (k-ind no-inv) -P DepthK s- ESBMC 



Fig. 3: Verification time to the loops subcategory. 


Tools CBMC CPAchecker (k-Ind InvGen) CPAchecker (k-ind no-inv) -P DepthK a- ESBMC 



Fig. 4: Verification time to the embedded systems programs. 


approach consists of converting a SystemC program into a 
C program, and then it performs the proof of the properties 
by mathematical induction using the CBMC tool Q. The 
difference to the one described in this paper lies on the 
transformations carried out in the forward condition. During 
the forward condition, transformations similar to those insetted 
during the inductive step in our approach, are introduced in the 
code to check whether there is a path between an initial state 
and the current state k\ while the algorithm proposed in this 
paper, an assertion is inserted at the end of the loop to verify 
that all states are reached in k steps. 

Donaldson et al. describe a verification tool called 
Scratch 0 to detect data races during Direct Memory Access 
in the CELL BE processor from IBM 0. The approach used 
to verify C programs is k-induction, which is implemented 
in the Scratch tool using two steps: the base case and the 
inductive step. Scratch can prove the absence of data races, 
but it is restricted to verify that specific class of problems 
for a particular type of hardware. The steps of the algorithm 
are similar to the one proposed in this paper, but it requires 
annotations in the code to introduce loops invariants. 

Kahsai et al. describe PKIND, a parallel version of the tool 
KIND, used to verify invariant properties of programs written 
in Lustre 1^ . To verify a Lustre program, PKIND starts three 
processes, one for base case, one for inductive step, and one for 
invariant generation, note that unlike ESBMC, the k-induction 
algorithm used by PKIND does not have a forward condition 
step. This happens because PKIND is used for Lustre programs 
that do not terminate. Hence, there is no need for checking 
whether loops have been unrolled completely. The base case 
starts the verification with k = 0, and increments its value 
until it finds a counterexample or it receives a message from 


the inductive step process that a solution was found. Similarly, 
the inductive step increases the value of k until it receives a 
message from the base case process or a solution is found. 
The invariant generation process generates a set of candidates 
invariants from predefined templates and constantly feeds the 
inductive step process, as done recently by Beyer et al. 0. 

V. Conclusions 

The main contributions of this work are the design, imple¬ 
mentation, and evaluation of the k-induction algorithm based 
on invariants, as well as, the use of the technique for the 
automated verification of reachability properties in embedded 
systems programs. To the best of our knowledge, this paper 
marks the first application of the k-induction algorithm to a 
broader range of embedded C programs. To validate the k- 
induction algorithm, experiments were performed involving 
142 benchmarks of the SV-COMP 2015 loops subcategory, and 
34 ANSTC programs from the embedded systems benchmarks. 
Additionally, we presented a comparison to the ESBMC with 
k-induction, CBMC with k-induction, and CPAChecker with 
k-induction and invariants. 

The experimental results are promising; the proposed 
method adopting k-induction with invariants (DepthK) deter¬ 
mined 11.27% more accurate results than that obtained by 
CPAChecker, which had the second best result in the SV- 
COMP 2015 loops subcategory. The experimental results also 
show that the k-induction algorithm without invariants was 
able to verify 49.29% of the programs in the SV-COMP 
benchmarks, and k-induction with invariants (DepthK) was 
able to verify 66.19% of the benchmarks. We identified that 
k-induction with invariants determined 17% more accurate 
results than the k-induction algorithm without invariants. 
















For embedded systems benchmarks, we identified some 
improvements in the DepthK tool, related to defects in the 
tool execution, and possible adjustments to invariant generation 
with PIPS. This is because the results were inferior compared 
to the other tools for the embedded systems benchmarks, 
where DepthK only obtained better results than CBMC tool. 
However, we argued that the proposed method, in comparison 
to other state of the art tools, showed promising results 
indicating its effectiveness. As future work, we will improve 
the robustness of DepthK and tune the PIPS parameters to 
produce stronger invariants. 
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